The present invention relates to LSI design assets (intellectual properties) for building a system-scale LSI and management thereof.
Enhanced LSI packaging technology for integration has made it possible to mount most of the elements required for building a system on one semiconductor chip.
When designing such a system-scale LSI, system designers may utilize circuit modules that have previously been designed within and possessed by the company and the like they belong to as the company""s intellectual assets or those purchased from an external supplier. These design assets are called Intellectual Properties (IPs).
Nowadays, such IPs are supplied from IP developers (vendors) to IP users via diverse distribution channels. For example, some IP vendor companies render a line of their proprietary IP articles open to the public on their Web site. Alternatively, some IP broker such as Virtual Component Exchange (VC) and IPTC Corporation manage the locations of IP articles of a plurality of IP vendors and render them open to the public.
Generally, IP articles of trade are sold as a combination of design data and documentation. Design data of IP includes hardware descriptions of the product implementation of the IP, its operation model, simulation test bench, expected values of simulation, etc. Its Documentation includes outside-usage specifications for IP user, verification procedural descriptions, restrictions for use, design records, bug check lists, etc.
In general, simulation is used as means for checking to see whether designers built the IP implementation product correctly. A variety of patterns of simulation runs check for operation that does not conform to the specifications. It is ideal to prepare as many simulation patterns as for all specifications (regarding the values of signals). Because of a huge quantity of combinations of specifications (regarding the values of signals), testing all cases is not practicable. Consequently, as one of the means for measuring variation in simulation, an index such as source code coverage for HDL code is used. In a publication xe2x80x9cTaxonomy of Functional Verification For Virtual Component Development and Integration Version 1.1xe2x80x9d of the Virtual Socket Interface Alliance (VSIA), the organization for standardizing IPs in the USA, hardware source code coverage and functional coverage are described as verification metrics.
In a broad sense, the function of source code coverage is such that it regards one of possible states on a state machine, signal toggle, branch-to-instruction by conditional branch, etc. as one unit, supervises the simulation run for whether it executed each unit, and counts up all units executed at the end of simulation.
As an example, the coverage for conditional branches is illustrated below. Assume that the following source code is written. Here A and B are conditional expressions, and if condition is true, THEN is executed; if false, ELSE is executed.
To execute all THEN and ELSE statements once, it is sufficient to execute the above source code twice. For example, execute THEN-A and THEN-B statements in the first time execution, and execute ELSE-A and ELSE-B statements in the second time execution. However, two cases other than the above are possible in this source code; that is, a combination of THEN-A and ELSE-B and a combination of THEN-B and ELSE-A. If bugs exist in these combinations of statements, they cannot be detected by the source code coverage for conditional branches.
Through consideration of the above circumstances, the source code coverage is expanded to a path coverage that is upgraded source code coverage. For a sequence of if statements and case statements as illustrated above, the path coverage additionally takes what path (combination) in which statements have been executed into account. In this respect, the path coverage is functionally superior to the above-illustrated source code coverage for conditional branches.
A general procedure in which an IP user purchases an IP article from an IP vendor is as will be described below.
The IP vendor designs and verifies their proprietary IP implementation product. Concurrently, the IP vendor prepares documentation of the IP product. When the documentation has been completed, information content about the IP (exclusive of the disclosure of the IP product itself), which is free of secrecy problem, is rendered open to the public to interest people in purchasing the IP. On the other hand, an IP user looks for an IP that provides user-desired function (for example, USB interface, MPEG decoder, etc.) via the Internet or the like. The IP user searches the Web sites of IP vendors and IP brokers for desired IP. The user may select from several IP candidates for purchase through consideration of performance, cost, risk, and other matters, based on the information obtained prior to agreements that must be made with an IP vendor when buying an IP. The user determines to buy an IP from an IP vendor and makes an agreement with the IP vendor. Then, the IP vendor delivers the IP product and documentation including secret information to the IP user and the IP user pays the money for the IP and licensing to the IP vendor.
Aiming at facilitating circuit module reutilization, Kei Suzuki, et al. attempted to map the values of signals that the input and output pins of a circuit module are to have at a specific time and their sequences over time in implementing the functions of the module; reference xe2x80x9cOwL: An Interface Description Language for IP Reusexe2x80x9d pp. 403-406. Circuit module operations described in interface specifications, that is, function-specific timing charts and the like are graphically represented on the computer, using a state transition machine. The state machine representation aids in understanding the circuit module specifications. It can be used to verify connection between two circuit modules and build an automatic design process such as synthesizing signal patterns.
The above-described IP distribution flow involves some problems for both IP user and IP vendor.
First, a problem for IP users is posed when they look for an IP providing for user-desired function. Because different IP vendors and IP brokers render different types of information open to the public, there is no firm index dependable in selecting an IP. This problem is explained in terms of IP quality. Some IP vendor provides bug detection curves, another IP vendor provides only check lists. Yet, another IP vendor provides a coverage degree of source code. In this respect, consequently, IP users have difficulty in determining what IP is the best quality.
Next, a drawback of currently used verification indexes, typically, source code coverage, will be discussed. Source code coverage is, surely, one index for measuring variation in simulation. However, even if the source code coverage is 100%, it does not mean covering all variations of IP product (circuit module) operation. In some case, bugs are revealed only after executing a certain code description by a certain number of times. In some case, bugs are revealed only when statements are executed in specific sequence. With source code coverage, there is a possibility of failure to debug.
Accordingly, the best possible alternative in the present situation is that, in addition to applying 100% of source code coverage, random test patterns are run to debug undetected bugs until debugging reaches a saturation point, but not complete. It is possible that randomly run test patterns detect bugs by chance, however, it is not sufficient for users as an objective index of verifying IP functionality.
On the other hand, IP vendors probably wish they would push their proprietary IPs by explaining distinctive features thereof from other corporate IPs. In view of IP quality, IP vendors wish they would push their IPs in distinction from other corporate ones by asserting that their IPs are higher quality than others. However, a publicly known index of verifying IP functionality is solely source code coverage that is generally used as described above. Applying 100% coverage of source code is minimum requirement and demonstration of IP functions using source code coverage data is not effective for IP vendors to attain their purpose to make their own IPs distinct from other corporate ones.
The above is also true even if the path coverage that is upgraded source code coverage is used. No doubt, the path coverage is better in considering combinations of statements and more simulation patterns need to run. However, there is still a possibility of failure to debug for cases where bugs can be detected only after executing a combination of statements by a certain number of times or more.
All the above-described problems are due to using simulation for verifying IP functionality. For specifications of a circuit module of IP, the number of times of possible execution of simulation is variable and infinite. Thus, an infinite number of combinations of simulation patterns occur. As indexes (metrics) of verifying that the model conforms to the specifications, however, there are only a few ones such as source code coverage and path coverage. If these indexes are satisfied (reaching coverage of 100%), there are no indexes of verification in more depth. Thus, IP users have difficulty in determining which IP is better when comparing IPs and IP vendors have difficulty in pushing their own IPs in distinction from other competitive corporate IPs.
In addition to the existing indexes of verification range such as hardware source code coverage and path coverage, the present invention provides a higher-level index of verification range with infinite degrees. According to this index, what extent or degree to which IP functionality has been verified is determined. The thus determined degree of verification is expressed by a validation level that is added to IP information to ensure the reliability of the verified functionality of the IP.